Business Analyst Community & Resources | Modern Analyst

Continuing a project in the penumbra...

enavarro — Tue, 27 Nov 2007 04:14:00 GMT

INTRODUCTION

Being dropped in the middle of a project that is already in a bad shape (over budget, over schedule and under compliance) is not easy (or funny). So try to make the best of it and get out of it alive.

On most cases, you get a project start with the business case or whatnot, then continue on with a chain of events. On most of my encounters I have dealt with projects already started and left in the Bermuda Triangle to drift or where the end was reached with no particular direction. The usual case of this type of situations comes from the mind-set of the culture the individuals are involved in. Regardless, you will have about no time for testing, little time for development and the who cares attitude. Not to mention you dont want to look stupid in front of the client going over to them and asking the questions that should've been asked beforehand.

Well this has been my case for the past 2 projects, they were already started, got derailed, no documentation whatsoever and an ever-present pressure to finish off because its already over budget. I can tell you now its not an easy task to come in SWAT Teamstyle and continue a project. So I made it... twice... with relative success, here are a few pointers.

THE TIPS

Tip#1: Focus on goals and measurable outcomes not on reconstructing whatever happened

I met some friends who make extensive use of CIMOSA, which is a simple yet effective approach. I borrowed some of their knowledge, and decided to focus on the KPI's and CSF's (see Definitions section), that is derail from the temptation of reconstructing the past design and unmade documentation from virtually zero requirements documentation or whatsoever.

Tip #2: Make sure that you get your project manager in check with the tasks

I noticed that even if the requirements documentation was bad, dissecting the requirements into an Excel spreadsheet and then assigning the project tasks that related to that specific requirement worked wonders with only a 4 to 16 hour effort (time is porportional to size). So you can actually give intelligent feedback to the PM and focus on the result: compliance to contract.

Tip #3: As cruel as it sounds, stick to the contract

Yes, I HATE mediocre work, poor solution design and giving the client something I know that doesn't solve their pains. Yet, in all honesty, you are not going to solve that organizations problems in a week, or 2. It will take some extensive work that was previously undone and HAS to be performed in order to really attack the root causes of problems, otherwise, you can and will possibly transfer the problems from functional organizational unit, or make it worse. So make sure to meet contracted demands in due time.

Tip #4: Dont forget to write it though

Even if you cant solve all of an organizations problems and need to focus on the task at hand, make sure to write all this stuff up. Bring it up at an internal status meeting and make sure your sales people get a hold of this information. If you can forsee substantial business improvement within your client's operation, he will appreciate you taking the initiative and bringing up intelligent assessments (and possible HR investment from your company to further analyze this and make a business case).

DEFINITIONS

KPI = Key Performance Indicator - measurable outcomes of a specific process that can tell you if you are headed in the right direction

CSF = Critical Success Factors - business goals that have to be met in order to comply with the business needs

Obstacle Analysis: How Problematic Scenarios Occurring during Requirements Analysis can be Nullified

Wed, 24 Oct 2007 03:46:00 GMT

Analysts everyday and in every domain of business come across obstacles in their analysis and efforts that prevent them from best meeting the needs of the business. These obstacles can be in the form of business processes, or system limitations, or both. Furthermore, a considerably big obstacle can be potentially detrimental to the spirit and purpose of a project. Obstacle Analysis is a tool that provides a systematic approach to overcoming those obstacles. Tackling road-blocks carefully and comprehensively can aid in achieving the mission of a project and in turn, satisfy customers.

I recently came across a research paper that revolved around the topic of Obstacle Analysis. The tool was applied to identify contingency requirements governing the mechanism of an unpiloted lightweight, experimental aircraft. Unsurprisingly soon after reading the paper I was under the impression that Obstacle Analysis was used mainly for increasingly autonomous, goal-oriented applications where safety was paramount. By “safety” I mean if one is going to build a flying, unmanned aircraft, you also want to build in autonomous safety features that would otherwise be handled by humans to prevent the vehicle from flying toward a collision. Besides, I don’t think there many on this portal, yet, who engineer requirements for real-time and embedded systems or tangible, moving objects.

Fortunately, I also quickly realized that Obstacle Analysis could be useful in conventional, (object-oriented) software requirements engineering aimed for desktop applications that we all work with daily. Hence, I feel confident in writing this entry expecting that it will be of use to other fellow analysts. I read the paper, read it once more, highlighted the main points, and promptly applied the tool to one of my smaller and uncomplicated projects to start with. You might notice that it's main usage comes in the requirements analysis phase.

So without any further ado, what exactly is Obstacle Analysis? Many of us may have already used it unwittingly in some informal way or another. In my own words, and to not plagiarize the paper, Obstacle Analysis is a systematic approach to identifying, analyzing and neutralizing obstacles that hinder the accomplishment of a necessary goal.

The following is an explanation of the steps involved:

IDENTIFY THE SUB-GOAL (the paper calls this Goal, but for semantics purposes, I prefer to use of the term "Sub-goal")

What is the goal that for which you as an analyst are engineering requirements? This, most likely, is a sub-goal that when executed correctly will lead to the achievement of a bigger goal. What is a goal anyway? A goal is one or a set of results expected to materialize on successful execution of one or more tasks.

IDENTIFY THE AGENTS

Agents are participants who will implement or aid in the implementation of the sub-goals. This could software components, hardware objects, and humans. This is an important element of the analysis, in that identifying the agent itself might resolve the obstacle.

IDENTIFY THE OBSTACLES

If a goal is a behavior of the system that is desired, an obstacle is an element that keeps that goal from being accomplished. What is it that prevents the goal from being achieved? This is step is particularly cyclical in rational thought – a decent understanding of the application being built will aid in uncovering its weak points that might need attention. Tackling the weak points and making the system more robust, in turn, only deepens one’s understanding further…and the cycle continues.

IDENTIFY ALTERNATIVES TO THE OBSTACLE

It is here that we offer multiple solutions to eradicate the obstacle. It is imperative that we list as many solutions as possible since, the next step depends on this one. There are multiple ways to identify alternatives:

De-scope the goal itself. At first, this may sound brash. But on closer thought, we realize that it’s not uncommon to simply wipe the goal off the slate and shrink the scope. Resolving the obstacle may pose a budgetary or scheduling challenge which a team might not be willing to undertake. Hence, getting rid of the goal might actually be a viable option.
Assign a Different Agent so that someone or some other component of the system helps in accomplishing the goal without giving rise to the obstacle.
Add a New Goal to the existing one if it prevents the obstacle from arising again.
Modify the Goal in that the obstacle will not arise in accomplishing the new goal.
Change the Domain in a way that the goal simply does not occur and keeps the goal in tact.

SELECT AN ALTERNATIVE

Choose the option that will best tackle the obstacle and thus, aid in achieving the goal.

In conclusion, I believe this is a comprehensive tool to tackle obstacles that we as analysts face nearly everyday. One of the obstacles that I tackled for my project using this tool resulted in nullifying the malicious effects of the obstacle, remaining within the scope, accurately meeting the main goals of the business, and a cleaner, less-complicated code from development.

For your curiosity, the paper can be accessed from here. Thanks in advance for your thoughts, comments and corrections, if you see any, for others to gain from. I also thank Lutz, Patterson-Hine, Nelson, Frost, Tal, and Harris (2006) for their research.

A framework for defining competencies for business systems analysts

Adrian M. — Mon, 09 Jul 2007 02:48:00 GMT

If you are managing business or systems analysts, trying to identify the skills and competencies required of your analysts is not an easy task. The expectations placed upon the analyst vary widely from organization to organization. The variations are so drastic that the actual title doesn’t not say much about the type of work your analysts do.

I have interviewed business analysts who have only worked on the business side and were never involved in the creation or modification of a system. On the other hand, I have met business analysts whose only responsibility was to create functional specifications.

OK… so what does this mean?

First, let me say this: “It’s not what you’re called, it’s what you do!”

What this means is that you should not try to figure out the skills and competencies of an analyst by their title – you need to know exactly what types of tasks you are expecting your analysts to perform.

In order to do that I like to put some structure around this topic to help you discover the skills and competencies expected of your analysts.

Let’s try!

- The Analyst bridges the gap between business & technology.

- The analyst plays a number of roles.

- To perform each role, the analyst draws knowledge from a set of disciplines.

- Each discipline defines a set of activities which the analyst performs.

- Each activity takes inputs and produces outputs.

- Each activity requires a given set of competencies.

- These competencies may include analytical, business, and technical skills.

Simple Definitions:

Analyst = this refers to the person whose title is generally business analyst or systems analyst but may have titles as diverse as: IT Business Analyst, Requirements Engineer, Computer Analyst, Functional Analyst, etc.

Role = The role refers to the analysts’ expected function in a given project or team. It speaks to the behaviors, rights, and responsibilities that are expected from the analyst in a given context. This is where we often get in trouble as the role of the analysts changes from project to project and task to task. Many analysts have what is known as “role confusion” in the situations when he/she has trouble figuring out exactly the role(s) they are supposed to play.

Discipline = A discipline represents a branch of knowledge (part of a larger body of learning) which defines a set of activities to be performed as well as the competencies needed to perform the given activity. For example, “testing” is a discipline which defines a set of activities and competencies needed by a QA analyst while testing software,

Activity = An activity represents a task or effort that is expected to be performed by the analyst in the context of a given role. Each activity must be clearly defined as is usually represented as having: a purpose (why perform the activity), outcome (what are the results/artifacts of the activity), and a method (how to perform the activity).

Competency = In general, competency refers to one’s ability (qualification and capability) to perform a given activity. In the case of the analyst, this requires an appropriate mix of knowledge (theoretical understanding), skills (practiced ability) and attitudes (way of thinking and opinions).

At a high level, I like to categorize the competencies needed by business analysts and systems analysts as follows:

Analytical competencies – because first and foremost, the analyst is supposed to “analyze” – obvious but often overlooked by many organizations.
Business competencies – because the analyst is expected to understand and solve business problems.
Technical competencies - because, in many cases, business problems are solved using technical solutions (information systems).

Any thoughts? Would love to hear your feedback!

Tablet UML

Adrian M. — Thu, 05 Jul 2007 02:41:00 GMT

In most of the projects and organizations I have worked for I have seen a very interesting pattern:

- Developers get developer specific tools such as MS Visual Studio.

- Testers get testing specific tools such as Mercury TestDirector.

- Analysts get MS Word, Excel, and PowerPoint. The more "progressive" organizations might provide their business analysts and systems analysts with Visio.

Wow... cool!

If you think I'm venting, you right? I am venting!

To tell you the truth: I don't get it!

There are so many great tools for requirements management and system modeling yet most organizations have not yet realized that spending a few bucks on tools for their analysts can actually improve productivity and save them money in the long run.

My gut feeling tells me that this problem is closely tied to the view of the business analyst. The business analysis, as a profession, it's just beginning to bud.

I'm hoping that, soon, most organizations will begin to realize the value that business analysts and systems analysts bring to the table. When that happens, the shortage of qualified analysts will be evident and companies will try to find other ways to increase productivity. An adequate tool is one such way!

But I digress...

What triggered these thoughts (again) was that I stumbled upon a UML tool for the Tablet PC called Tablet UML. While I have not used the product - it's a very intriguing idea. Imagine being in a JAD session or brainstorming meeting and, instead of pen & paper, using a tablet PC to capture the models being discussed.

Technologies and tools such as these are going to become more and more important and valuable as organizations realize the importance of analysts and attempt to find new ways to increase their productivity.

Systems Analyst in the list of Best Careers 2007

Adrian M. — Sun, 24 Jun 2007 02:03:00 GMT

The Systems Analyst role is and will continue to be one of the best careers for a long time.

In their “Best Careers 2007” report, US News and World Report lists 25 professions that will continue to grow in demand.

With the advent of outsourcing, it is not surprising that the software engineer or web developer professions are NOT on the list...

...however, systems analyst is.

One of the most interesting quotes form this report is that the systems analyst "is among the most offshore-resistant computer-related careers".

Another interesting observation is that the majority of the 25 careers are high-touch/social occupations. In the US, we continue to see a trend of increased demand for careers which requires social interaction skills. Business Systems Analyst is one of them.

A couple more items of from the report about the Systems Analyst:

Median pay: $70,438
Job Market outlook: A
Attainability: A
Quality of Life: B
Prestige: B

If you are contemplating starting your career as a systems analyst you might also find the following resources useful:

A Day in the Life of a Systems Analyst

Computer Systems Analyst profile (U.S. Department of Labor)

Systems Analyst Community

Systems Analyst Resources

Salary Info for Business Systems Analysts